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REMARK? 

I. Introduction 

In response to the Office Action dated December 17, 2003, claims 5, 7, 11, 16, 18, 22, 27, 
29, 33 and 40 have been canceled, and claims 1, 6, 8, 12, 15, 17, 19, 23, 28, 30 and 34 have been 
amended. Claims 1-4, 6, 8-10, 12-15, 17, 19-21, 23-26, 28, 30-32 and 34-39 remain in the 
application. Re-examination and re-consideration of the application, as amended, is requested. 

II. Non-Art Rejections 

In paragraph (3) of the Office Action, claims 15-16 were objected to as being dependent 
upon ^Iflirn 1> when they should have been dependent on claim 12. 

Applicants* attorney has amended claim 15 and canceled claim 16 to overcome this 
objection. 

III. Prior Art Rejections 

A. The Office Action Rejections 

In paragraphs (4)-(5) of the Office Action, claims 1-3, 5-14, 16-25, 27-34, 36-38, and 40 were 
rejected under 35 U.S.C. §l03(a) as being unpatentable over Hunt, U.S. Patent No. 6,154,747 (Hunt) 
in view of Fischer, U.S. Patent No. 6,105,072 (Fischer). In paragraphs (8)-(9) of the Office Action, 
claims 4, 15, 26, 35, and 39 were rejected under 35 U.S.C. §1 03(a) as being unpatentable over Hunt 
and Fischer as applied to claims 1, 23, and 34, and further in view of Moore, U.S. Patent No. 
5,343,527 (Moore). 

Applicants* attorney respectfully traverse these rejections. 

B. The Applicants* Independent Claims 

Independent claims 1,12 and 23 are generally directed to checking a version of an abstract 
data type stored in a database. Independent claim 1 is representative, and comprises: 

(a) constructing an identifier for the abstract data type, wherein die identifier comprises a 
concatenation of various attributes for the abstract data type that is substantially unique to the 
abstract data type; 

(b) hashing the constructed identifier to generate a signature hash value for the abstract data 

type; 
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(c) storing the signature hash value in the database and a class definition for the abstract data 
type; and 

(d) comparing the signature hash value from the database with the signature hash value from 
the class definition after the class definition is instantiated in order to verify that the class definition 
is not outdated. 

Independent claims 6, 17 and 28 are generally directed to generating a signature hash value 
for checking a version of an abstract data type stored in databases- Independent claim 6 is 
representative, and comprises: 

(a) constructing an identifier for the abstract data type, wherein the identifier comprises a 
concatenation of various attributes for the abstract data type that is substantially unique to the 
abstract data type; 

(b) hashing the constructed identifier to generate a signature hash value for the abstract data 
type; and 

(c) storing the signature hash value in the database and a class for the abstract data type* 
Independent claims 8, 19 and 30 are generally directed to verifying a signature hash value for 

checking a version of an abstract data type stored in a database. Independent claim 8 is 
representative, and comprises: 

(a) accessing a first signature hash value from the database and a second signature hash value 
from a class definition for the abstract data type, wherein the first and second signature hash values 
have been constructed from an identifier for the abstract data type, the identifier comprises a 
concatenation of various attributes for the abstract data type that is substantially unique to the 
abstract data type, and the identifier has been hashed to generate the first and second signature hash 
values; and 

(b) comparing the first signature hash value with the second signature hash value after the 
class definition is instantiated in order to verify that the class definition is not outdated- 
Independent claim 34- is directed to at least one data structure scored in a memory for use in 

checking a version of an abstract data type stored in a database, the data structure comprising a 
signature hash value for the abstract data type generated from an identifier constructed for the 
abstract data type, wherein the identifier comprises a concatenation of various attributes for the 
abstract data type that is substantially unique to the abstract data type and the identifier is hashed to 
generate the signature hash value for the abstract data type. 
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C. The Hunt Reference 

Hunt describes a method using a plurality of hash tables to provide an object repository for 
object oriented application development and use. The merhod includes storing an object identifier 
and a representation of the object in a first hash table and storing data about the object and the 
object identifier in a plurality of paired hash tables with the hash tables organized in mirrored table 
pairs. The data about the object include an objects class name, object methods, return types, and the 
data values returned by object methods. The non-inverse hash tables of the mirrored table pairs 
support &2zy searches for objects while the inverse hash tables of the mirrored table pairs support 
searches for objects by object identifier. A system that implements the inventive method includes a 
first hash table for storage of data representing the object with an object identifier used as a key for 
Storage of the representing data and a plurality of mirrored table pairs for the storage of data about 
objects. In the non-inverse table of the mirrored table pairs, the data about the objects are used as 
keys to store an object identifier. In the inverse tables of the mirrored table pairs, the object 
identifier is used as the key for storage of the data about the data objects. The mirrored table paiis 
and hash table provide an efficient and economical object repository. Such aa object repository may 
be provided with a computer application at a nominal expense. Thus, object oriented applications 
may be developed without regard for whether the end user system includes an object repository. 

D, The Fischer Reference 

Fischer describes a method of operating computers in accordance with an enhanced object- 
oriented programming methodology that creates a framework for efficiendy performing automated 
business transactions. The object-oriented programming methodology is used in conjunction with a 
travelling program, Le., a digital data structure which includes a sequence of instructions and 
associated data which has the capability of determining at least one next destination or recipient for 
receiving the travelling program and for transmitting itself, together with all relevant data determined 
by the program to the next recipient or destination Using the methods described herein, the data is 
more closely bound to the program in such a way that objects may be most efficiently transferred 
from one computer user to another without the objects being previously known to the recipient 
computer user. The present invention utilizes object "cells" which are data structures stored, for 
example, on a disk that reflects a collection of (related) objects instances whose execution has been 
suspended, and which can be resumed later on the same or a different platform. The collection of 
object instances can be gathered together into cells (or "electronic forms") suitable fox storage or 

-12- 

G&C 30571.231-US-Ul 



PAGE 15/22 * RCVD AT 3/16/2004 8:36:06 PM [Eastern Standard Time] * SVR:USPTO-EFXRF-1/0 * DNIS:8729306 * CSID:+1 3106418798 * DURATION (mm-ss):05-24 



03-16-2004 05:46PM FRGM-Gatas & Cooper LLP +13106418798 J-182 P. 016/022 F-267 



transmission to another computer user in such a way that instances are unambiguously bound to 
their respective class definition. The present invention also creates improved tools for creating and 
using cells so that electronic forms can be defined using object-oriented techniques while allowing 
such forms to be easily transferred among a diverse population of computer users— without 
demanding that all users maintain compatible libraries of all object-class definition progtams and 
without demanding that all users maintain identical synchronized versions of that class. The 
invention provides a digital signature methodology to insure security and integrity, so that electronic 
forms (Le.„ cells) composed of a collection of objects can be received and executed by a user without 
putting the user at risk that some of the object classes embedded in the cell might be subversive 
"trojan horse" programs that might steal, destroy or otherwise compromise the security or integrity 
of the user's system ox data- 

E. The Moore Reference 

Moore describes a system and method for providing a reuser of a software reuse library with 
an indication of whether or not a software component from the reuse library is authentic and 
whether or not the software component has been modified. The system and method disclosed 
provides a reuser with assurance that the software component retrieved was placed in the reuse 
library by the original publisher and has not modified by a third party. The system and method 
disclosed uses a hybrid cryptographic technique that combines a conventional or private key 
algorithm with a public key algorithm. 

F. The Applicants* Claims Are Patentable Over The References 

Applicants* invention, as recited in the claims, is patentable over the references, because the 
claims recite limitations not found in the references. 

Nonetheless, the Office Action asserts the following: 

5. Claims 1-3, 5-14, 16-25, 27-34, 36-38, and 40 are rejected under 35 
U.S.G 103(a) as being unpatentable over Hunt US Patent No. 6,154,747 in view of 
Fischer US Patent No. 6,105,072. Hunt discloses a hash table implementation of an 
object repository. 

6. With regards to claims 1, 3, 6, 8, 10, 12, 14, 17, 10 3 21, 25, 23, 28, 30, 
32, 34, 36, and 38, Hunt teach es the construction of an identifier for die abstract data 
type where the identifier is substantially unique to the data type (Hunt, column 6 
lines 43-45, column 7 lines 42-49), the hashing of the constructed identifier to 
generate a signature hash value for the abstract data type (Hunt, column 6, lines 45- 
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50), the storing of the hash value in the database (Hunt, column 7 lines 1-3 and 
column 6 lines 48-50). Hunt fails to teach the storing of the hash value in the class 
definition and the comparing of the hash value from the database and the class 
definition. Fischer teaches a system for validating object-oriented components, 
Fischer teaches the storing of the hash value in the class definition (Fischer, Figure 4 
and column 30 lines 55-58) and the comparison of the hash values (Fischer, column 
30 line 66 - column 31 line 12). At the time the invention was made, it would have 
been obvious to a person of ordinary skill in die art to utilize Fisher's method of 
placing hash values within the object and comparing that hash value with another 
because it offers the advantage of preventing a too old or too new version of an 
object from inadvertendy operating on incompatible data (Fischer, column 4, lines 
19-49). 

7. With regards to claims 2, 9, 13,20,24, 31, and 37, Hunt and Fischer 
teach the instantiating of the class definition as a library function (Fischer, column 30 
lines 55-58), the accessing of the abstract data type via tite Kbrary function (Fischer, 
column 31 lines 6-10), and the comparison of the signature hash from the database 
and the class definition (Fischer, column 30 line 66-column 31 line 12). 

8. With regards to claims, 5, 7, 11, 16, 18, 22, 27, 29, 33, and 40, Hunt 
and Fischer teach the identifier comprising a concatenation of various attnbutes for 
the data type (Hunt, column 7 lines 42-48). 

9. Claims 4, 15, 26, 35, and 39 rejected under 35 U.S.C 103(a) as being 
unpatentable over Hunt US Patent No. 6,154,747 and Fischer US Patent No, 
6,105,072 as applied to claims 1, 23, and 34 above, and further in view of Moore US 
Patent No. 5,343,527. Hunt and Fischer, as described above, fail to teach the use of a 
relational database for storing objects. Moore teaches the use of a relational database 
to store objects (Moore, column 18, lines 14-21). At the time the invention was 
made, it would have been obvious to a person of ordinary skill in the art to utilize 
Moore's method of using relational databases because it provides a means for storing 
and providing objects that are available at the request of a workstation (Moore, 
column 3, lines 25-32). 

Applicants' attorney disagrees. Applicants' attorney asserts diat the references do not teach 
or suggest all the litnitations of Applicants' claims. 

For example, at the cited locations, the references merely disclose the following: 

Hunt> column 6 lines 43-45 (actually, lines 29-67) 

A preferred structure for object repository 18 that may be accessed by an 
instance of the gateway depicted in FIG. 3 is shown in FIG. 4. Object repository 18 
includes a single hash table 62 and hash table pairs 64, 68, 72, and 74 which are 
organised in mirrored table pairs. Each mirrored table pair is comprised of a non- 
inverse hash table and an inverse hash table. The inverse tables are so referenced 
because they reverse the key /value organization of the non-inverse hash tables. 
Mirrored table pair 64 stores class names for objects. Mirrored table pair 68 stores 
data regarding die methods used by the objects stored in repository 18 and mirrored 
table pair 72 stores data regarding return types for the methods of the objects stored 
in repository 18, Mirrored table pair 74 is used to store data values returned by the 
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methods for objects stored in repository 18. Hash table 62 is organized to store 
object data using an object identifier as a key. Preferably, the database used to 
implement the hash tables of repository 18 generate the key for storing information 
in a bash tabic by providing an object identifier (OID) as an argument to a hashing 
function* The value generated by the hashing function is used as a key for storing 
data in a hash table. Because use of serialized data object data would not be 
efficiendy hashed to generate a key > the hash table used to store object data does not 
have a corresponding inverse table. Instead, an OED is used as a key to Store object 
data in hash table 62 after the object data has been serialized, that is, converted to 
string data. An object's class name is stored in the non-inverse table 64a as the key 
for the OID of the corresponding data object Likewise, object methods are stoted 
in non-inverse table 68a as the key for die OID of the corresponding object and the 
return types for the methods of the objects are stored in the non-inverse table 72a as 
the key for the OID of the corresponding object. The data value returned by a 
method of an object is concatenated with the object's class name and method to 
generate a key that is used to store the OID in non-inverse table 74a, In the inverse 
table of each of the mirrored table pairs, the OID is used as the key to store the data 
value that is the key for the OID in the non-inverse table. 

Hunt, column 7, lines 42-49 (actually, lines 42-65^ 
Object identifiers are preferably generated by capturing system time in 
milliseconds since a certain date in 1970 and concatenating that value with the 
number of objects processed by the instance of interface 20 being used by an 
application 14. This object identifier (OID) is preferably generated in string form and 
is returned to application programs 14 as well as being used to store data in object 
repository 1 8* However, in distributed environments, two instances of interface 20 
may have processed the same number of data objects and may generate an object 
identifier at the same time. Accordingly, both instances would generate the same 
object identifier. As a result, the object identifier may be provided to the wrong 
instance of interface 20 for retrieval of the object without detection or an attempt to 
store different objects in the same repository with the same OID may occur. To 
reduce the likelihood of this occurrence, generation of the OED is performed as 
discussed above except a prefix string corresponding to the name of the server on 
which an instance of interface 20 is executing is concatenated to the OID. As 
instances of interface 20 likely execute on different servers in a distributed 
environment, this method of OID generation addresses the remote likelihood of the 
same OID being generated by different instances of interface 20. 

Hunt, column 7 j lines 1-3 (a ^maUy, lin es 1-28) 

Preferably, each hash table of object repository 18 is implemented with a 
Berkeley DB database system available from Sleepycat Software Inc. of Carlisle, 
Mass. and the programming language statements that implement instances of 
interface 20 conimunicate with the management system for the Berkeley DB through 
a thread extending to repository 18. The Berkeley DB database uses union data 
structures implemented in the C programming language. Preferably, one Berkeley 
DB is used for each of the nine hash tables required to implement the preferred 
structure discussed above. Eight of the Berkeley DBs are used for the four mirrored 
table pairs and the other Berkeley DB is used for the single hash table in the 
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preferred implementation. Berkeley DBs may be configured for one of three access 
methods. These aecess merhods are binary tree (mode 1), extended linear hash table 
(mode 2), and taxed or variable lertgdi record (mode 3). Preferably, the Berkeley 
databases are configured to operate in mode 2 for use as hash tables. The 
prograrnming statements that implement interface 20 preferably include five (5) 
instances of a Java class with four of the five class instxances controlling access to a 
mirrored table pair and the fifth instance of the class controlling access to the single 
hash table. The Berkeley DB preferably used to implement repository 18 also 
includes a management system that handles transactions, locking, logging, shared 
memory caching and database recovery. In addition, Berkeley DB supports C, C++, 
Java and Perl application programming interfaces. 

Fischer^ column 30. lines 55-58 (actually T lines 55-65A 
If the source code has been located, then at block 1220, it is compiled and 
the hash of the source is computed. If the computed source hash matches that 
defined in the authenticated aspect of the cell, then the class is accepted. It is 
possible that the source hash is based not on the exact source, but rather a 
normalized form, for example, with the comments removed and nonessential 
spacing deleted. Thereafter, in block 1220, the class authorization is established 
associated with the source code. The source definition is compiled using whatever 
compiler is appropriate to the source definition if multiple languages are supported. 

Fischer, c^trtn 3Q T line 66 — column 31. line.12 

Processing then continues in block 1232. If the prior processing involved a 
block 1230, then the located version of the p-code is loaded from the local file 
repository or within the cell itself. The hash of the p-code is computed as it is loaded. 
A check is made to ensure that the precompiled p-code is in a format eligible for 
being processed by this interpreter/executor and the class authorization is 
established that is associated with the p-code. A check is made to determine whether 
the computed hash of the p-code equals the expected value as defined in the 
authenticated part of the cell. If there is a match, then the class is accepted. If not, an 
error indicator is generated. The processing at 1232 additionally saves the hash of the 
original source which is given in p-code. 

Fischer, r ^ji^ 4 lines 19-49 

This provides integrity by insuring diat changed 'library" or template 
versions of a class program cannot inadvertendy operate on older instance data; or 
that other incorrect versions of a class program cannot be inadvertently used (and 
cause confusion ot damage) when a cell is activated at different times by a variety of 
users (recipients) [even if one of the users may have a class program with a matching 
name]. The unambiguous binding between instance and class may be provided in a 
variety of ways including: 

by binding an object instance in a cell to its class by including the class 
definition- i.e., the class program logic itself, whether it be in source, p-code or 
matching code— as part of the cell data structure. 

By binding an object instance in a cell to its class by including in the cell a 
[cryptographic] HASH of at least one of: the SOURCE instructions (or normalized 
version thereof); che pseudo-code (p-code) instructions resulting from compilation; 
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or che machine language code resulting from cornpilarion—for the class program 
definition. 

The binding correlates to each instance with precisely the correct 
corresponding class program— so that another class with the same name, or an 
anachronistic version (too old or too new) of the class— cannot be inadvertently 
selected to operate on the existing version of instance data, when the cell is reloaded. 
This is especially useful for class programs that perform critical or sensitive 
functions. In this fashion, "master" class definitions may be changed without 
impairing or confusing existing instances that depend on the specification of the 
class definition at the time the instance was created, . 

Moore r column 18 T lines 14-21 (actually, lines 14-33) 
A plurality of software component records 1001 are shown in memory 38 
each having font components: the encrypted software, the encrypted hash digest, the 
encrypted key, and the descriptive plaintext component. The software components 
may be stored in a repository, a relational database, a flatfile, object oriented data 
base ox any other, means. The retrieval means 1003 and the storage means 1005 
would then interface with the storage subsystem for the storage and retrieval of 
software component records. Also shown in memory are cataloging means 1007, 
classifying means 1009, and indexing means 1011. Also shown are the classifying 
criteria 1013, software component reviews 1015 and indexes 1017. The retrieval 
means 1005 may also contain a search capability that permits reusers connected to 
the reuse library to search through software component records 1001 uses a search 
criteria, key words, classification criteria, etc. This search capability could use 
information contained in the descriptive plaintext component of the software 
component records. 

The cited locations of the references, taken individually or in any combination, do not teach 
or suggest all the limitations of the Applicants' claims. 

For example, the above portions of Hunt do not teach or suggest constructing an identifier 
from a concatenation of various attributes for an abstract data type that is substantially unique to the 
abstract data type. Instead, Hunt merely states that the object identifier (OID) is generated by 
capturing system rime in milliseconds since a certain date in 1970, concatenating that value with the 
number of objects processed by the instance of interface 20 being used by an application 14, and 
prefixing a string corresponding to the name of the server on which an instance of interface 20 is 
executing. 

In another example, the above portions of Fischer do not teach or suggest storing a 
signature hash value both in a database and a class definition for the abstract data type, so that at a 
later time the signature hash value from the database can be compared with the signature hash value 
from the class definition, after the class definition is instantiated, in order to verify that the class 
definition is not outdated. Instead, Fischer merely describes how the source code of a. class 
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definition is hashed, but this hashing function is performed each time the source code is located, and 
nothing in Fischer supporrs the assertion that the result from the hashing is stored with the source 
code itself. Moreover, in Fischex, the source code of the class definition is hashed, not an identifier 
for an abstract data type, wherein the identifier is constructed from a concatenation of various 
attributes for the abstract data type. 

In yet another example, the above portion of Moore does not teach or suggest storing 
signature hash values for abstract data types both in a database and a class definition for the abstract 
data type. Instead, Moore merely describes the use of a relational database to store objects. 

Finally, none of the references do not teach or suggest comparing the signature hash value 
from die database with the signature hash value from the class definition after the class definition is 
instantiated in order to verify that the class definition is not outdated. 

Consequently, even when combined, Hunt, Fischer and Moore do not teach or suggest 
Applicants' invention. Moreover the various elements of Applicants' claimed invention together 
provide operational advantages over the references. In addition, Applicants' invention solves 
problems not recognized by the references. 

Thus, Applicants submit that independent claims 1, 6, 8, 12, 17, 19, 23, 28 9 30, and 34 are 
allowable over Hunt, Fischer and Moore. Further, dependent claims 2-4, 9-10, 13-15, 20-21, 24-26, 
31-32 and 35-39 arc submitted to be allowable over the references in the same manner, because they 
are dependent on independent claims 1, 6, 8, 12, 17, 19, 23, 28, 30, and 34, respectively, and thus 
contain all the limitations of the independent claims. In addition, dependent claims 2-4, 9-10, 13-15, 
20-21, 24-26, 31-32 and 35-39 recite additional novel elements not shown by the references. 

IV. Conclusion 

In view of the above, it is submitted that this application is now in good order for allowance 
and such allowance is respectfully solicited 



-18- 

G&C 30571. 231-US-U1 



PAGE 21/22 * RCVD AT 3/16/2004 8:36:06 PM [Eastern Standard Time] * SVR:USPTO-EFXRF-1/0 * DNIS:8729306 * CSID:+131 06418798 * DURATION (mm-ss):05-24 



03-16-2004 05:48PM FRQM-Gatas & Cooper LLP 



+13106418798 



T-182 P. 022/022 F-267 



Should the Examiner believe minor matters still remain that can be resolved in a telephone 
interview, the Examiner is urged to call Applicants' undersigned attorney. 

Respectfully submitted, 

GATES & COOPER IXP 
Attorneys for Applicants 

Howard Hughes Center 
6701 Center Drive West, Suite 1050 
Los Angeles, California 90045 
(310) 641-8797 



Date: March 16. 2004 



GHG/ 



By:_ 




Name: Vieorge; 
Reg. No.: 33,500 
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